r? @b-naber

(rustbot has picked a reviewer for you, use r? to override)

@bors try @rust-timer queue

⌛ Trying commit 44c45ca0492db8f40cdcb19ff7dbfca05e95be75 with merge daa8f4a9835d98cf1139c088d10b29b4e8e084a5...

since replace doesn't use swap since #83226)

Wrong link?

@the8472 Oops, yup, wrong link. Should be #83022

☀️ Try build successful - checks-actions
Build commit: daa8f4a9835d98cf1139c088d10b29b4e8e084a5 (daa8f4a9835d98cf1139c088d10b29b4e8e084a5)

Finished benchmarking commit (daa8f4a9835d98cf1139c088d10b29b4e8e084a5): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 643.928s -> 645.194s (0.20%)

r? compiler

Finished benchmarking commit (fd9bf59): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 647.471s -> 646.658s (-0.13%)

• changes are all to secondary benchmarks
• only notable was coercions debug incr-full regressing by 5.7%, but that's acceptable given what we expect benefits to be here w.r.t. codegen.
• marking as triaged.

@rustbot label: +perf-regression-triaged

In noticed a quite large performance (15-20%) regression in an analytical database I'm building with [u8; 24] and [u8; 28] arrays. I bisected the regression between nightly commits e6d4725 and b2b34bd. This PR was the obvious suspicion since this changed how arrays that small are copied around. There's a lot of small arrays being moved around in the database I'm building. I didn't notice any performance regressions for other data types (u128 or u64 etc.) I've only tested on aarch64-apple-darwin so far. I haven't published my work yet, but I can come up with a benchmark program if needed.

(In case you don’t already know about it: cargo-bisect-rustc should bisect within the rollup PR of that last commit, to hopefully give you the offending PR or in/validate it’s this one)

I'll verify the offending PR using cargo-bisect-rustc. In the meantime here's a simple benchmark which reproduces the issue on my Macbook M1 Pro:

#![feature(test)]
extern crate test;
use test::Bencher;

#[bench]
fn bench(b: &mut Bencher) {
    b.iter(|| {
        let data = vec![[1u8; 24]; 1024 * 1024];
        let mut new_vec = Vec::with_capacity(1024 * 1024);
        for entry in data {
            new_vec.push(entry);
        }
    });
}

$ cargo +nightly-2023-06-06-aarch64-apple-darwin bench
    Finished bench [optimized] target(s) in 0.00s
     Running unittests src/main.rs (target/release/deps/benchmarks-0c0dfc3834e16b96)

running 1 test
test bench ... bench:   5,899,666 ns/iter (+/- 137,707)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out; finished in 5.34s

$ cargo +nightly-2023-06-07-aarch64-apple-darwin bench
   Compiling benchmarks v0.1.0 (/Users/tuomas/rust/benchmarks)
    Finished bench [optimized] target(s) in 0.18s
     Running unittests src/main.rs (target/release/deps/benchmarks-0c0dfc3834e16b96)

running 1 test
test bench ... bench:   9,094,616 ns/iter (+/- 46,638)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out; finished in 8.23s

Please open an issue so we can track this. Closed PRs aren't a good place for it.

Will do.